1. Technical Field
The present disclosure relates to exception page programming, and, in particular, to a system and method for providing an exception page programming tool for use with a page description language file where the exception page programming tool can display exception page programming within the context of a print job.
2. Description of Related Art
Page description languages (“PDLs”) are computer languages and/or file formats that can be translated into printed documents. Many printing systems can accept the PDL data directly without pre-processing by another device such as a computer. PDL files are generally designed for describing how characters, graphics, and/or images should be printed on a substrate by a printing device. PDL files generally store printing data in a more abstract manner than a pixel-wise image file. For example: rather than describing a square pixel-by-pixel, a PDL file may describe the square in terms of position, size, color etc. These types of PDL files may have several advantages over bitmap files, such as file size and platform robustness. Additionally, some printing systems may receive a PDL file directly with minimal or no processing before the file is received by the printing system.
When setting up one or more PDL files for printing, specialized printing tools sometimes assist a user in controlling the settings, printing flow, and/or other parameters for setting up a printing job for a printer system. For example: it is common to apply exception level programming to a PDL file before printing commences. Generally, “exceptions” in this context, are items not included in the original page content of the PDL file or contain different item level programming from the body of the job. These are considered to be “Exceptions” to the job-level programming that defines the body of the job. Exceptions may be applied to one or more pages, and exceptions generally do not modify the PDL file itself, but rather provide an effective way to make last minute changes and/or specialized settings. Tools that apply exception level programming are called exception page programming tools.
Typically, exceptions can be set for paper stocks (covers, stock exceptions, page inserts), page sequencing (chapter starts), image quality and image shifting. Other exceptions may include subset finishing, imposition, and page level annotation. For example, a PDL file may include image quality information, such as contrast settings, color settings and other settings associated with certain aspects of the PDL file. An exception may be applied to a particular page or a subset of pages that override these PDL properties.
Though, not all exceptions override PDL parameters; for example: pages may be inserted in between pages, such as tabbed pages to delineate sections and/or chapters. These inserts are also sometimes treated as exceptions. Additionally, exception level programming may apply to the current stock (sometimes referred to as the paper stock). The stock is the type of medium or material that is to be printed on. Many modern printing systems have multiple sources of stock, separated by color, quality, weight, medium, material, finishing and/or coating material. For example, a PDL file may have 30 pages of text and one photographic quality page; an exception may be associated with that photographic quality page to utilize a medium more suitable for printing a photographic level of detail and/or quality.
In addition, some exception level programming may include “subset finishing” features, where a subset of pages, sheets, or aspects are modified. For example, a subset of pages may have certain attributes that are modified in the printing process, such as the use of high quality paper for a certain chapter of a PDL file. Also, an exception (or subset finishing) may be applied for stapling a range of pages within a print job. These changes are also considered exception level programming.
There are at least two general types of objects that exceptions select and manage: pages and sheets. Pages are usually discrete pieces of print-related data contained within the PDL file that are to be printed. Exceptions that may be applied to pages include chapter starts, image quality adjustment and image shifting. Sheets usually are pieces of paper. Each sheet has two sides, a front and back, that can be printed on. A page can be mapped to a side of a sheet. It is common practice to map pages to one or both sides of a sheet, e.g., page 1 is printed on side 1 of sheet 1, while page 2 is printed on side 2 of sheet 1, or alternatively, page 1 is printed on side 1 of sheet 1, while page 2 is printed on side 1 of sheet 2. Thus, in certain contexts, the two words may be used interchangeably.
Also, there are two general classifications of print job programming: job-level programming and page-level programming. The job level programming tools usually modify features for the entire job. Page-level programming is usually done by modifying and/or creating exceptions by utilizing an exception programming tool; although it is possible to utilize exceptions to modify multiple pages and/or sheets.
Exception programming varies according to many aspects, including but not limited to: the PDL language, the printing system used, the time constraints, expense constraints and stock availability. Also, exception page programming may be conducted by a user from several locations. A user may control the programming from a computer that is directly attached to the printing system, from a computer that may access the printer through a network, from a computer that is part of the printing system, from a digital front end and/or may be a user interface attached directly to the printing system itself.
Usually, a graphical user interface (abbreviated herein as “GUI”) is utilized to assist in exception page programming. Additionally, software that creates, edits, converts PDL files may also contain integrated modules and/or software to provide exception level programming. Currently exception programming is generally viewed in terms of “exception only” views, i.e. views that only include the pages that have exceptions applied to them. There has been a need to provide a more effective way to view exceptions while doing exception page programming than viewing only the exceptions.
As with most graphical user interfaces, however, there is sometimes a trade-off between processing speed and ease-of-use. Consider the following: within other software tools and in some operating systems, it is possible to view images as icons or thumbnails. Icon viewing is where a small picture, image or graphic is used to show a generic display for an item type, e.g., an operating system may show the same image for all word-processing files of a certain file format.
Thumbnails, on the other hand, may provide a preview or a “sneak-peak” of some or all of the content found in the underlying file. For example, some operating systems, when viewing files within a certain directory (or folder) display a small picture of what the file actually looks like when opened. For example, if a user has a jpeg file of a picture taken of a fish during a fishing expedition, the file may show a smaller image of that picture (and thus a small “thumbnail” of the fish in question).
Thumbnails are not necessarily limited to image and picture files. Certain types of files may be “rendered” and/or interpreted. For example, consider a word-processing file: a thumbnail image may be an image of the file (or a particular page) when opened by the word processor, or alternatively, it may be a rendering of a file (or a particular page) as may appear when the file is printed. Generally a thumbnail image of the file when printed is called a WYSIWYG thumbnail (What You See Is What You Get).
The drawback of such thumbnails is the overhead that may be incurred when showing a thumbnail representation of a file. For example, if the file has lots of data associated with describing a file in terms of elements and properties (e.g. “square”, “size=x,y”, “color=blue”, “position=2 inches, 4 inches”) then before a thumbnail representation can be shown, the file must be interpreted by a program so the image may be rendered. Interpreting and/or rendering may have significant overhead because of the memory and processing resources that may be required to interpret and/or render a thumbnail image. There has been a need for improved utilization of resources when displaying thumbnails.